> > "In the previous message, Doug Davis said..." > > > > The real question is one of; how to beat vendors into fixing the > > problems reported by it.. (grumble grumble)... > > > > Or failing that, has anybody devised a way to: > > A: use LD_PRELOAD to replace the random() (or srandom()) or whatever function > fsirand calls with one that ignores the passed init seed, and produces its > own, to make it work right...? > or > B: Make available sources for a replacement fsirand that will work on SunOS > and other affected OS's that one can build and run. There has been a patch for it, for over 2 years. 1063470 Non-random file handles can be guessed, leading to security hole. NFS jumbo patch fixes it. > or > C: I resorted to letting the PIDs get way up there, say over 10,000 then > kicked the system down to single-user, did a umount -a, and ran it on all > the filesystems (except /, and /usr, of course). Making sure it wasn't > shut down and rebooted, the PIDs just continue from what they were when > it was up in multi-user. > > So, all I get in nfsbug output is the UID bug (which goes away if I don't > export as root, but sometimes that is needed). I wonder if anybody > has put together the affected module from non-restricted sources, > so people can fix it? I know that Suns NFS jumbo patch doesn't > affect the UID bug, as it is still there. I have no idea if it > fixes the fsirand prolbem or not... Yes, it does fix the fsirand problem. UID bug? you mean the uid_t bug, uid/gid values are supposed to be 32 bits wide, while SunOS's uid_t is 16, it affects all OS's that have uid_t == 16 bits, eg IRIX, etc have this problem too, there is a patch for it, as well. 1095935 NFS server in which a client presenting a 32-bit uid in which the 16 low-order bits are 0 gets interpreted as root on the server.